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Abstract. There have been many proposals for access control models 
and authorization policy languages, which form the basis for the design 
of access control systems. Most, if not all, of these proposals impose re- 
strictions on the implementation of access control systems, limiting inter 
alia the type of authorization requests that can be processed or the struc- 
ture of the authorization policies that can be specified. In this paper, we 
provide a formal characterization of the features of an access control sys- 
tem. However, we impose few restrictions on the actual implementation 
of such a system. In adopting this approach, we are able to define and 
articulate a number of desirable properties of an access control system in 
terms of our model, thereby laying the foundations for formal methods 
that can be used to analyze access control systems. We also illustrate 
that concrete instantiations of the framework yield important insights 
into the behavior of existing proposals for access control systems. 



1 Introduction 

One of the fundamental security requirements in modern computer systems is 
access control, a mechanism for constraining the interaction between (authen- 
ticated) users and protected resources. Generally, access control is enforced by 
a trusted component (historically known as the reference monitor), which is 
typically implemented by two functions: an authorization enforcement function 
(AEF) and an authorization decision function (ADF). The AEF traps all at- 
tempts by a user to interact with a resource (usually known as a user request) 
and transforms that request into one or more authorization queries (also known 
as authorization requests) which are forwarded to the ADF. 

Most access control systems are policy-based. That is, an administrator spec- 
ifies an authorization policy, which, in its simplest form, encodes those autho- 
rization requests that are authorized. The ADF takes an authorization query 
and an authorization policy as input and returns an authorization decision. For 
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this reason, it is common to refer to the AEF and ADF as the policy enforcement 
point (PEP) and policy decision point (PDP), respectively; it is this terminology 
that we will use henceforth. 

An authorization policy is merely an encoding of the access control require- 
ments of an application using the authorization language that is understood 
by the PDP. It is necessary, therefore, to make a clear distinction between an 
abstract policy and a realizable policy: the former is an arbitrary function from 
requests to decisions; the latter is a function that can be evaluated by the PDP. 
Given a particular policy language, there might be some abstract policies that 
are not realizable, which may be a limitation of the policy language in practice. 
The access control system used in early versions of Unix, for example, is rather 
limited. An important consideration, therefore, when designing an access control 
system is the expressivity of the policy language. 

The increasing prevalence of open, distributed, computing environments, 
means that we may not be able to rely on a centralized authentication func- 
tion to identify authorized users. This means that authorization decisions have 
to be made on the basis of user attributes (rather than user identities) . In turn, 
this means that the format of authorization queries needs to be rather more flex- 
ible than that used in closed, centralized environments. The draft XACML 3.0 
standard, for example, uses a much "looser" query format than its predecessor 
XACML 2.0. If we have no control over the attributes that are presented to the 
PDP, then a malicious user (or even a user who wishes to preserve the secrecy 
of some attributes) may be able to generate authorization decisions that are 
more "favorable" by withholding attributes from the PEP. A second important 
consideration, therefore, is whether authorization policies are guaranteed to be 
"monotonic" in the sense that providing fewer attributes in an authorization 
query yields a less favorable outcome. 

Related Work and Motivation. There is an extensive literature on languages 
for specifying authorization policies. Much of this work can be traced back to 
the early work of Woo and Lam, which considered the possibility that different 
policies might evaluate to different authorization decisions [T5] . More recent work 
has considered larger sets of policy decisions or more complex policy operators 
(or both) [2I4I5I6I7I8I9I12I13I14I15I16TT7] . 

However, most of these proposals focus on closed systems in which requests 
have a fixed format, typically based on the subject-object-action paradigm. 
Moreover, few proposals attempt to look at the whole system, focusing instead on 
the details of the policy language. The two notable exceptions are XACML [IB] 
and PTaCL [§]: the former provides a rich set of language features but lacks 
formality, while the latter provides formal semantics for policy evaluation, with 
some restrictions on what policies can express. However, both XACML and 
PTaCL make assumptions about the structure of policies: like many proposals 
in the literature, XACML and PTaCL are "target-based" [415161718115116117] . 

The diversity of computing environments and the increasing automation of 
business processes make it necessary to support a wide variety of authorization 
policies. It seems unlikely, for example, that the access control requirements of 



a social network will have much in common with those of an enterprise system. 
We believe, therefore, that it is important to design a framework that makes 
no assumptions about policy structure, policy decisions or policy operators. The 
framework should allow for the comparison of different design choices: What 
happens if I include decisions that can distinguish between missing information 
and non-matching information, or between missing information and malformed 
information? What happens if I use one particular method for combining the 
results obtained from evaluating sub-policies rather than some other method? 
And how do these methods interact with different choices for the set of deci- 
sions? The framework should also allow for the analysis of the policies that are 
expressible and to identify those that are not. 

Contributions. In this paper, we develop an abstract framework for access control 
systems. This framework includes the structure of authorization queries, the 
specification of authorization policies and the evaluation of requests with respect 
to policies. Informally, we regard an authorization policy as a formula in some 
multi-valued prepositional logic. A "policy formula" contains "policy variables" 
which are atomic policies; atomic in the sense that they are indivisible. Atomic 
policies are combined using policy operators defined over a set of policy decisions 
(which correspond to truth values taken from the set of values defined by the 
logic). For every request, a policy decision is assigned to each atomic policy. 
The valuation on atomic policies is extended to a valuation on policy formulae 
by recursively evaluating the sub-formulae and combining the values using the 
policy operators. 

A number of these facets of our framework have appeared in the literature 
in some form: atomic policies are rather similar to the base policies defined by 
Crampton and Huth [6]; we have already noted that there are many proposals 
in the literature for policy operators defined over multi-valued decisions; and 
XACML and PTaCL provide frameworks for the specification and evaluation of 
a particular class of policies. However, the combination of these facets within 
a formal framework in order to reason about access control systems, the rigor 
of the semantics and the generality of the framework are, to the best of our 
knowledge, unique. 

We also show that the framework is not merely of technical interest. In par- 
ticular, we demonstrate that particular instantiations of our framework give rise 
to access control systems that are very similar to proposals in the literature such 
as XACML. Hence, we are able to examine various proposals in the literature 
and evaluate their suitability as building blocks for access control systems. 

Structure of the Paper. In the next section we describe our framework for specify- 
ing access control systems. In Sec. [3] we investigate properties of an access control 
system, focusing on expressivity and monotonicity. In Sec. |4]we instantiate our 
framework and illustrate some of the problems that may arise in target-based pol- 
icy languages and access control systems such as PTaCL [5] and XACML |15ll6j , 
two "target-based" policy languages. In the final section of the paper we sum- 
marize our contributions and describe our plans for future work. 



2 The Framework 



In this section we describe the various components of our framework before 
introducing the formal definition of an access control system (Def. [3]). The com- 
ponents of the framework are illustrated in Appendix [B] using information flow 
and role-based access control policies. 

2.1 Authorization Queries 

An authorization query defines the representation by which user requests will 
be presented to the policy decision point (PDP). Typically, some intermediate 
component of the access control architecture will transform a user request into 
one or more authorization queries. In XACML - which provides a standard- 
ized reference architecture for access control [T])J Figure 1] - this component is 
called the context handler, which will extract information from the user request 
and, optionally, seek information from other components of the access control 
architecture (policy information points in XACML) in order to construct an 
authorization query that can be processed by the PDP. 

We assume throughout, as in XACML, that the PDP only takes the autho- 
rization query and the policy as input. In other words, the PDP communicates 
only with the context handler and requests no additional information from ex- 
ternal sources. 

We assume that the PDP recognizes some fixed set of data types T and that 
each data type t <E T can take some set of values, denoted by dom(i). We also 
assume that for each type t G T and for each pair of values x and y of type t, the 
PDP can evaluate whether x equals ?/, and can recognize that a value x claimed 
to be of type t does not belong to dom(t). Finally, we assume that the PDP can 
evaluate whether a value x of type t appears in a set of values, each of which is 
of type t. 

There is considerable freedom in the way in which an authorization query 
might be represented. Typically, the representation will depend on where cer- 
tain information relevant to access control is assumed to reside. It may be the 
case, for example, that one implementation might have the context handler push 
some information relevant to policy evaluation to the PDP, while in a different 
implementation that information might be encoded in the policy itself. We will 
assume that an authorization query is represented using attributes of the re- 
questing user, the requested resource and the requested interaction between the 
user and the resource. An authorization query may also include environmental 
information such as the time at which the requested access was made or the 
location of the user. More formally, we introduce the following definition. 

Definition 1 Let M denote a set of attribute names. Let each attribute name 
a be associated with a type type(a) and let each type t be associated with a set 
of values dom(i) that can be taken by attributes of type t. Then an authorization 
request is a set {(ai,vi), . . . (a m ,v m )}, where m G dom(type(ai)) for all i. 



Henceforth, when no confusion can arise, we write dom(a) rather than 
dom(type(o;)). We write Q(7V) to denote the set of possible requests, omitting 
M when it is obvious from context. The definition above does not preclude the 
possibility that cti — ctj for some i ^ j. That is, a query may contain two or more 
attributes with the same name. We show, in Sec. [4j that multiple attributes val- 
ues may have undesirable implications for policy evaluation and discuss a more 
restricted form of requests. 

2.2 Policy Decisions 

We consider a set of decisions Dec, which corresponds to the set of constants in 
a multi-valued logic. Typically, we will include lp ("allow") and Op ("deny"), 
which correspond to 1 (true) and (false) , respectively, in standard propositional 
logic. 

It is common to consider a third value indicating that it is not possible (or 
not appropriate) to assign a conclusive decision to a policy. Typically, this is 
used when policies are applicable only to some strict subset of the set of all 
requests. Such a decision is particularly useful for attaching a meaning to policy 
sub-formulae, which is then resolved to a conclusive decision by the application of 
some policy operator. In XACML, this third decision is called "not applicable" , 
which we will denote by _Lp. 

Conversely, Tp may be returned by a policy operator to indicate that its 
arguments conflict in some sense. We might define an operator ©, such that 
d\ © d 2 = T P if di,d 2 E {lp, Op} and d\ ^ d 2 . Such an operator could be used 
to indicate that two policies p\ and p 2 returned different conclusive decisions. 

We can also associate side effects with decisions. In this way, we can encode 
obligations that are attached with allowing or denying certain authorization 
queries. Then the semantics for policy operators must define how sets of obliga- 
tions are combined in addition to defining how policy decisions are combined. 
Space limitations prevent us from exploring this matter further here. 

2.3 Atomic Policies 

An atomic policy is some representation of an authorization policy. The main 
requirement of an atomic policy is that the PDP can furnish the policy with 
a truth value (i.e. a decision) by inspection of the authorization query. Atomic 
policies may take many different forms, depending on the way in which the 
authorization query is represented and the desired authorization policy. In Ap- 
pendix [Bj we illustrate two different forms of atomic policy that could be used 
to realize different types of authorization requirements. 

Given a set of authorization queries Q, a set of atomic policies A and a set 
of decisions Dec, a valuation function Eval : Q x A — > Dec is used to associate 
atomic policies with decisions. The valuation function would form part of the 
functionality of the PDP and it is here that the assumptions about the abilities 
of the PDP are crucial: for an atomic policy p and a request q, Eval(g,p) will be 
defined by examining attribute values in the request. 



It is important to note that even for very simple atomic policies, the def- 
inition of the valuation function is a rather delicate matter. In particular, the 
interpretation of missing attributes and of "junk" attribute values has a sig- 
nificant impact on policy evaluation. We return to this matter in Sec. [3] and 
Sec.lH 

2.4 Policy Operators 

Given a set of atomic policies A, we can build more complex policies from atomic 
policies using policy operators, each of which has the form © : Dec fe — > Dec for 
some integer k ^ 1. Table [1] defines some particularly useful unary and binary 
operators. A policy operator could be included in a policy language for a variety 
of a different reasons. 

— A policy operator may be used to combine, and possibly resolve conflicts 
between, the decisions returned by two (or more policies). 

We define binary operators Ap and Vp , which act in the same way as logical 
conjunction and logical disjunction in Kleene's 3- valued logic, respectively. 
We also define binary operators Ap and Vp, which have similar semantics to 
Ap and Vp for conclusive decisions (lp and Op), and essentially ignore the 
value _Lp; for example, _LpAplp = _Lp, while _Lp Aplp = lp. These operators 
act in a way similar to the deny-overrides and allow-overrides algorithms in 
XACML. 

— A policy operator may be used to restrict the scope of a policy and to 
determine the outcome of policy evaluation if a request is within scope. 
XACML targets may be interpreted in this way. 

We define a binary operator ?p, where p\ ?p P2 returns the evaluation of pi 
if the evaluation of p\ returns lp and returns J_p otherwise. 

— A policy operator -ip may be used to reverse policy evaluation (swapping 
the decisions lp and Op). We might include such an operator if we wish to 
provide a rich policy language that can be used to define arbitrarily complex 
policies. 

— A policy operator may be used to transform a policy with "gaps" (one that is 
not defined for some requests) into one without gaps. Deny-by-default and 
allow-by-default are examples of such operators. For instance, the unary 
operator ^p has the effect of removing _Lp by simply converting it to a 
deny: if policy p evaluates to _Lp, then policy ~pp evaluates to Op. 

Definition 2 Given a set of atomic policies A, a set of decisions Dec and a set 
of operators Ops, the set of realizable policies V(A, Dec, Ops) is defined induc- 
tively: 

— a G V(A, Dec, Ops) for every a G A; 

— for all pi, . . . ,pk G V(A, Dec, Ops) and for every k-ary operator © G Ops, 
k>l, ®{pi,...,p k ) G V{A, Dec, Ops). 



Table 1. Operators over {lp,0p,_!_p} 



di 


d 2 


-^pdi 




di Ap d2 


di Ap d2 


di Vp d2 


di Vp d2 


di ?p d2 


di XXp d2 


lp 


lp 


Op 


lp 


lp 


lp 


lp 


lp 


lp 


lp 


lp 


Op 


Op 


lp 


Op 


Op 


lp 


lp 


Op 


J-p 


lp 


J-p 


Op 


lp 


-lp 


lp 


lp 


lp 


-Lp 


J-p 


Op 


lp 


lp 


Op 


Op 


Op 


lp 


lp 


-Lp 


J-p 


Op 


Op 


lp 


Op 


Op 


Op 


Op 


Op 


-Lp 


Op 


Op 


-Lp 


lp 


Op 


Op 


Op 


-Lp 


Op 


-Lp 


J-p 


-Lp 


lp 


-lp 


Op 


J-p 


lp 


lp 


lp 


-Lp 


J-p 


-Lp 


Op 


-lp 


Op 


Op 


Op 


-Lp 


Op 


-Lp 


J-p 


-Lp 


-lp 


-lp 


Op 


J-p 


-Lp 


-Lp 


J-p 


-Lp 


J-p 



Given A, Dec and a valuation function Eval : A — > Dec, we define the extended 
valuation function Eval + : Q x V(A, Dec, Ops) — > Dec for the set of realizable 
policies as follows: 



Eval+(«?,p) = 



Eval(g,p) ifp&A, 
)(Eval+(g,pi), . . . , Eva\+(q,p k )) if p = e(pi, • • • ,Pk)- 



2.5 Access Control System 

Definition 3 An access control system is a tuple (Q, A, Dec, Ops, Eval), where 
Q is a set of authorization queries; A is a set of atomic policies; Dec is a set of 
policy decisions; Ops is a set of policy operators; and Eval : Q x A — > Dec is a 
valuation function for atomic policies. 

Given a set of requests Q and a set of decisions Dec, an arbitrary autho- 
rization policy may be regarded as a function n : Q — > Dec. We call any such 
function an abstract policy. 

Definition 4 Given a system S — (Q, A, Dec, Ops, Eval) and an abstract policy 
7T : Q — > Dec, we say that S realizes ir if and only if there exists a policy 
p G V(A, Dec, Ops) such that for all requests q, n(q) = Eval + (g,p). 

When no confusion can arise, we may use the term policy to refer to cither an 
abstract policy or a concrete policy written using A and Ops. And when A, Dec 
and Ops are obvious from context, we will simply write V for the set of realizable 
policies V(A, Dec, Ops). 



3 General Properties 



An access control system (Q, A, Dec, Ops, Eval) may realize a large number of 
policies. It might therefore be useful to be able to characterize some general 



properties of those policies. In particular, we want to characterize the notion of 
monotonicity for a policy, which indicates whether a request is more likely to 
be granted if more information is supplied. In this section, we also define the 
notion of completeness of a system, which is concerned with the expressivity of 
the policy operators. Finally, we outline some other properties, such as safety 
and static decision-based analysis. 

3.1 Monotonicity 

Informally, a policy is monotonic whenever removing information from a request 
does not lead to a "better" policy decision. Such a property is of particular 
relevance in open systems, where users might be able to control what information 
they supply to the access control system. A system in which all realizable policies 
are monotonic means that a malicious user gains no advantage by suppressing 
information when making a request. 

We model information hiding using a partial ordering ^q on Q; the intuitive 
interpretation of q ^q q' is that q contains less information than q' . We also 
need to specify what it means for a decision to "benefit" a user, and thus we 
assume the existence of an ordering relation on Dec; again, the intuitive 
interpretation of d\ ^p d2 is that the decision g?2 is of greater benefit than diH 
In Seed] we provide specific definitions for each of these relations. 

Definition 5 Given a set of authorization queries (Q, ^q) and a set of decisions 
(Dec, ^p), an abstract policy tt : Q — > Dec is monotonic if and only if for all 

q <q q' n(q) ^ P vr(g')- 

We say that an access control system (Q, A, Dec, Ops, Eval) is monotonic if every 
realizable policy is monotonic. 

Definition 6 An operator © : Dec fc — > Dec is monotonic if and only if for all 
d\, . . . , dk £ Dec and d[, . . . , d' k £ Dec with d\ ^p di, 1 ^ i ^ k, 

®(d[,...,d' k ) < P ®(d u ...,d k ). 

Informally, a binary operator © is monotonic if increasing the truth value 
in any one of its arguments has the effect of increasing the truth value of the 
computation. 

Proposition 7 An access control system (Q,A, Dec, Ops, Eval) is monotonic if, 
and only if every policy in A is monotonic and every operator in Ops is mono- 
tonic. 

Proof. The result follows by a standard induction over the structure of policies. 

In Sec. IH we instantiate our framework with a particular definition of atomic 
policies. By assuming some restrictions on the structure of requests, we can prove 
the monotonicity of a system using results from partial logic [3]. 

3 Note that we consider this relation to be statically defined over decisions, and to be 
independent of the request. 



3.2 Completeness 



As we noted above, any realizable policy p G V corresponds to an abstract 
policy 7r : Q — > Dec. However, in general, the converse is not necessarily true: 
some abstract policies might not be realizable by a given system. Trivially, for 
example, a system without any atomic policies does not realize any abstract 
policy. It follows that the set of abstract policies that can be realized by a 
system represents an intuitive notion of expressivity. A system that can realize 
every every abstract policy is said to be complete. More formally: 

Definition 8 An access control system (Q, A, Dec, Ops, Eval) is complete if, and 
only if for any abstract policy 7r : Q — > Dec, there exists a realizable policy 
p G V(A, Dec, Ops) such that for all q G Q, Eva\ + (q,p) = ir(q). 

The completeness of a system (Q, A, Dec, Ops, Eval) will depend on the defi- 
nition of atomic policies, the set Ops and Eval. Intuitively, in order to prove the 
completeness of a system, we need to have for each potential attribute a and 
each value v an atomic policy that can distinguish (a, v). We propose in Sec. [4] a 
representation of atomic policies that can distinguish attribute name- value pairs 
in this way, from which we can prove a completeness result. 

It is worth observing that in general, if a system is both monotonic and 
complete, then the ordering over requests is limited to the identity relation. 

Proposition 9 Let S = ((Q, ^q), A, (Dec, ^p), Ops, Eval), where |Dec| > 1, be 
a monotonic, complete system. Then is the identity relation. 

Proof. Let us consider two requests q and q' such that q ^g q' and q q' . Since 
| Dec | > 1, there exist d\ and di such that d\ d2- Since S is complete, there 
exists a policy p generated by S such that Eval(p, q) = d\ and Eval(p, q r ) = ^2, 
which contradicts the monotonicity of p. 

Informally, this result states that if we wish to have a (non-trivial) monotonic 
system then we cannot expect to have a complete system. Instead, what we 
should aim for is a system that realizes all monotonic, abstract policies, and 
such a system is said to be monotonically- complete. 

3.3 Other properties 

The notions of monotonicity and completeness are examples of general properties 
we can characterize. We believe that our framework is expressive enough to 
characterize many other useful properties. Due to space restrictions we only 
sketch here some properties of interest, leaving their full characterization and 
analysis for future work. 

Safety An important question for an access control system is to know whether 
a particular access request is authorized at some point in the future, potentially 



through several modifications of the security configuration. This is known as the 
safety problem, and has been shown to be undccidable in general [?] . 

In order to model the notion of safety in our framework, we first need to 
model the ability to change the security configuration. Hence, we introduce a 
new attribute modif , such that dom(modif ) = V — > V, and we write n for values 
of modif. Intuitively, given a policy p, fj,(p) stands for the policy obtained by 
applying the modification fi. 

Since a policy modification is simply an attribute value, then deciding 
whether such a modification is allowed or not can be directly managed by the 
policy itself. In other words, given a policy p, a request q and a modification 
/z such that /i belongs to q, Eval + (g,p) = lp means that the policy p can be 
modified to the policy /i(p). The safety problem is then equivalent to knowing, 
given a policy p and a request q, whether there exists a sequence of modifications 
over p such that q is allowed. We represent this concept with the relation 
where p^ q informally means that p eventually enables q. Intuitively, p^ q if, 
and only if, cither p authorizes q, or there exists a modification p allowed by p 
(not necessarily with the request q) such that p(p) ~> q. More formally, we have: 



where V and A denote logical disjunction and conjunction, respectively. In gen- 
eral, the safety problem considers whether p ^ q holds for policy p and request 
q. Note that this relation ~> is not structurally inductive, since p(p) is not struc- 
turally smaller than p, and therefore ~» is in general undecidable (there might 
exist an infinite chain of modifications). However, in some cases, for instance 
when the number of basic permissions is finite, or when no modification of the 
policy is allowed, then the relation ~> may be computable. 

Static Decision-based Analysis In addition to monotonicity and safety, there 
is a wide range of properties one might want to verify over a given policy by 
considering as a propositional formula. For instance, the satisfiability problem 
consists in checking whether there exists a valuation on the atomic policies such 
that the policy is true, in other words whether the policy allows at least one 
request. Such a problem can be extended to constraint satisfaction problems, 
for instance in order to know which attribute values are missing in a request in 
order to allow the request. 

4 Attribute-Based Access Control 

In this section we look at the framework in practice. In particular, we illustrate 
how the framework can be instantiated to produce a concrete access control sys- 
tem that implements attribute-based access control using target-based policies. 
Given a particular format for atomic policies, we explore how different restric- 
tions on the request format and different choices for the Eva I function give rise 
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to systems with greater expressive power, on the one hand, to systems with 
stronger guarantees about the evaluation of policies on the other. 

Throughout this section we use a particularly simple, perhaps the simplest, 
representation of atomic policies. Given a set of attribute names TV and a domain 
dom(a) for each attribute a G TV, we write A(Af) to denote the set of atomic 
policies {(a, v) : a G TV, v € dom(a)}. 

4.1 A Monotonic System 

In this subsection, we choose Three = {lp,0p, ±p} for the set of decisions and 
define the ordering x ^3 y if and only if x = y or x = _Lp. Note that other order- 
ing relations are possible: we choose this particular one because it corresponds to 
the "degree-of-definedness" relation used in partial logic to reason about miss- 
ing (truth) values [3. ; this ordering corresponds in an obvious way with our wish 
to characterize missing information. We show that if we restrict the format of 
requests in a particular way then it is possible to construct a monotonic access 
control system. 

Requests. A request q is a set of attribute name- value pairs 
{(ax, vi), . . . , (a m , v m )}, with the restriction that each attribute name 
may occur at most once in a request We write Qi for this set of requests. A 
request may be incomplete, in the sense that there may exist a G TV such that 
((Xi, Vi) ^ a for any i. And a request may be malformed, in the sense that there 
may exist (a.i, Vi) G q such that Vi G" dom(ai). In other words, a request may be 
missing certain attribute names and may include attribute values that do not 
belong to the domain of the attribute. We define the following order over 
requests. 

Definition 10 Given two requests q and q' , q q' if and only if, for all 

(a, v) G q such that v G dom(a), (a, v) G q' . 

It is consistent for us to define, for all requests {(a,v)}, {(a,v)}, 
with equality if and only if v — o, since we may interpret the request as 
{(a, o)}. Note that does not define a partial ordering on Q\, since it is not 
anti-symmetric0 However, it is easy to establish that the relation =q 1s where 
q =q 1 q' if and only if q q' and q' q, is an equivalence relation. 

The Evali Function. Recall that Evali assigns a value to atomic policies. We 
define Evali recursively over the length of the request. We interpret the empty 
request as (a, o), where o signifies both a missing attribute (a "hole") and a 

4 That is cti — aj if and only if i = j. 

5 For example, if q — {(a,v)} and q' — {(a, v), (a 1 , o)}, then q q' and q' q, 
but q 7^ q . 



value that does not belong to the domain of a. We define 

!1 P if q 9 (a,v), 
P if q 3 (a, v') and v' e dom(a) and v' / v, 
_Lp otherwise. 

In other words, if the request contains a matching attribute name- value pair 
then lp will be returned; if the request contains a matching attribute name and 
a non-matching (legitimate) attribute value then Op will be returned; otherwise 
_Lp will be returned. The policy (actionID, read), for example, will return lp 
whenever the request contains the pair (actionID, read); this corresponds to the 
allRead policy in Appendix 151 

It is important to emphasize that we do not assume that the equality pred- 
icate necessarily returns either true or false. In particular, we consider the case 
that a request contains the pair (a, o), where o stands for any value that does 
not belong to dom(a). In this case, the truth value of v — o is indeterminate, in 
which case Evali(g, (a, v)) = -Lp. 

Moreover, we have the following result (the proof of this proposition and 
other results, can be found in Appendix [A"| . 

Proposition 11 Let q, q' £ Qi such that q=Q 1 q 1 ■ Then for all atomic policies 
(a,v), 

Evali(q, (a, v)) = Evali(g', (a, v)). 

The above result tells us that all elements of the same equivalence class 
induce the same valuation on the set of atomic policies. Hence, Evali(q, (a, v)) the 
evaluation of a request is determined solely by the attributes to which legitimate 
values have been assigned. In the following, we work modulo the equivalence 
relation =q i; with being a partial order defined on the set of equivalence 
classes. 

Proposition 12 For all requests q, q' G Q\ such that q q' and for all atomic 
policies (a,v) 6 A{N), 

Evali(q, (a,v)) ^ 3 Evali(q', (a, v)). 

Building Policies. Using the policy operators ~p, ->p and Vp, we can construct 
the following policies: ~p(a, v) and (a, v) Vp ~^p(a, v); ^p(a, v) returns lp if the 
request contains a matching attribute value v for attribute a (and Op otherwise) , 
while (a,w) Vp ->p(a,v) returns lp if the request contains the attribute a and 
that a valid value is associated with it (and _Lp otherwise). The latter policy can 
be used to identify well-formed requests. We are not aware of any other policy 
language or policy algebra, with the exception of PTaCL [S] , that supports this 
type of "request interface" policy. 

Similarly, the policy operators Ap and Ap can be used to construct useful 
policies such as (a, v) Ap (a',v'), which evaluates to lp only if both attributes 



are present in the request and have the appropriate values, and (a, v) Ap (a', v'Y, 
which evaluates to lp if exactly one attribute is present with the correct value 

Proposition 13 The system (Qi, A(J\f), Three, {-ip, Ap, Vp, XXp, ?p} , Evali) is 
monotonic. 

Proof. The result follows directly from Proposition Proposition [T^] and the 
fact that the operators ->p,Ap, Vp,XXp and ?p are monotonic. 

Note that the operators ~p, Ap and Vp are not monotonic, and therefore 
cannot be used to build a monotonic system. 

Proposition 14 The system (Qi, A(Af), Three, {-ip, Ap, Vp, XXp, ?p} , Evali) is 

monotonically complete. 

Proof. Let it be an abstract monotonic policy. We show that there exists a policy 
p(n) 6 V\ that realizes ir. 

(2ij *sQi) is a finite partially ordered set, so we may enumerate its elements 
using a topological sort. That is: Qi = {qo,qi, ■ ■ ■ ,q n }> f° r some n determined 
by Af and dom(a), a € N; and qi qj implies that i $C j. Since the empty 
request is less than any other request, we necessarily have q n = 0. 

For any non-empty request q — {(a±, v±), . . . , (ct m , u m )}, we define the policy 
t q = (ai,vi) Ap . . . Ap (a m ,v m ). Note that Eval^ (q',t q ) = lp for all q' ^ q. 

Now, for any request q G Q\: either q = qo, in which case Eval^g, t qi ) = _Lp, 
for all t qi , or q — qi, for some i ^ 1; Eval^~(g, t qi ) — lp; and, for all j > i, 
Eva\^ (q,t qj ) ^ lp. In other words, this index i "identifies" the request q. We 
want to define an operator SV : Three™ — > Three, such that, given the evaluation 
of t qi , . . . , t qn , this operator "identifies" the request qi corresponding to this 
evaluation (i.e. the maximal element equal to lp), and returns ir(qi). 

More formally, the operator (B n takes a n-tuple of decisions (di, . . . , d n ), such 
that each di = Eval^(g, t 9< ), for some q, and is defined as: 



We now prove that © ff is monotonic. Intuitively, we want to prove that the 
order over tuples of decisions implies the order over requests, in order to use 
the monotonicity of tt. Let d%,...,d n £ Three and e^,...,^ S Three with 
d'i ^p di, 1 < i < n. Let q' and q be the requests identified by (d^, . . . ,d' n ) 

6 We can also define the policy (a, v) Vp (a', v'), which evaluates to lp if at least one 
of the attributes is present and has the required value. Note that we can, trivially, 
encode an access matrix using atomic policies: the matrix entry (s, o, a) may be 
encoded as ~p(subjectID, s) Ap ~p(objectID, o) Ap ~p(actionID, a); the matrix is 
encoded as the disjunction of all such authorized triples. In Sec. 14.21 we demonstrate 
that there is a strong correspondence between atomic policies and the targets used 
to define policies in XACML and PTaCL. 




7r(g m ) if m = max{l ^ i ^ n \ di = lp}, 
7r(0) otherwise. 



and (d\, . . . , d n ), respectively. By definition, we have . . . , d' n ) ~ ir(q') 

and ® v (di, . . . , d n ) = 7r(g). Furthermore, let m be the maximal index such that 
d' m = lp, it follows that q' = q m . Since d' m d m , we can deduce that d m = fp, 
implying that q m q, that is, q' q. By hypothesis, ir is monotonic, and 
thus we have 7r(g') ^p 7r(g), allowing us to conclude that is monotonic. 

Finally, we know, by a result of Blarney [3], that any monotonic operator 
can be built from {-ip, Ap, Vp, Ap}. In other words, the policy (B 7r (t qi , . . . , t qn ) 
belongs to V\, and therefore we can conclude that 7r can be realized by 
{Qi,A{N), Three, {-. P , A P , V P , A P , ? P } , Evali). 

Proposition 15 The system (Qi, A(Af), Three, {-ip, ~p, Vp} , Evali) is com- 
plete. 

Proof. The structure of this proof is similar to that of Proposition [TJJ with 
the difference that we consider now the abstract policy tt is not necessarily 
monotonic. We show that there exists a policy p(ir) 6 V\ that realizes n. 

Concretely, we consider the enumeration over the requests, and we build the 
same operator However, in this case, we do not need to prove the monotonic- 
ity of (Bn, and we use instead the fact that the logic {lp, Op, _Lp, ->p, ~p, Vp} is 
functionally complete jS], which ensures that can be built from {-ip, ~p, Vp}. 

The above propositions provide guidance to the system designer. She can 
choose, for example, between a system that realizes only and all monotonic 
policies, and a system in which all policies are realizable, but some may be non- 
monotonic. Clearly, the choice depends on the demands of the application and 
the constraints of the underlying environment. While we cannot make this choice 
for the policy designer, our framework can only help her make that decision. 

4.2 XACML as an Instance of the Framework 

XACML is a well known, standardized framework for access control systems and 
is best known for the language it defines for specifying policies. A policy written 
in XACML may be viewed as a tree in which (i) the leaves are XACML rules 
(ii) interior nodes whose children are all leaves are XACML policies, and (iii) all 
other nodes are XACML policy sets. Each XACML rule is associated with an 
effect, which is taken from the set {lp,0p}. All XACML rules, policies and 
policy sets define a target, which is used to limit their respective applicability. 
The target language is expressed over the attributes of a request and involves the 
comparison of attribute values in the target with attribute values in the request. 
The effects of applicable child rules are combined to produce a decision for each 
policy; the decisions for each applicable policy and policy set are combined to 
produce a decision for each policy set. 

Using A(N) as the set of atomic policies and Evali as defined in Section [4~T1 
we note a strong correspondence between our framework and XACML. A policy 
of the form {{ol\, v-\) Ap . . . Ap (a m , v m ))?pd encodes an XACML rule whose tar- 
get matches those requests containing attribute values v\, . . . ,v m for attributes 



ai, . . . , a m , respectively, and whose effect is d. Moreover, the operators Ap and 
Vp act, respectively, like the deny-overrides and allow-overrides algorithms 
used in XACML. The completeness of our framework allows us to assert that 
any of the policy-combining algorithms specified in XACML can be expressed 
in our framework. 

The fact that XACML uses non-monotonic operators means that it is pos- 
sible, in principle, to change the decision reached by a policy by withhold- 
ing attributes from a request. Note, in particular, that lp Ap Op = Op, while 
lp Ap _Lp = lp. This suggests that care should be exercised when authoring 
XACML policies because it may be possible for a malicious user, by withholding 
attribute information, to cause policy evaluation to return lp rather than Op. 

4.3 A Non-Monotonic System 

In practice, we may wish to include multiple values for the same attribute. The 
most obvious example arises in role-based access control systems, where a request 
may contain several role values. We now discuss the consequences of modifying 
the structure of requests in this way, and we write <2* for the set of such requests. 

The previous function Evali is changed to the function Eval*, such that 
Eval*(g, (a, v)) returns lp whenever (a, v) belongs to q, _Lp if q contains no pair 
of the form (a, v') for any v' G dom(a), and Op otherwise. Most attribute-based 
access control systems, including XACML 3.0 and PTaCL, choose to evaluate 
requests in this way. However, it is trivial to sec that such a strategy is not 
monotonic with respect to the ordering ^q, defined in Section 14.11 In particu- 
lar, for v,v' £ dom(a) with v ^ v' , we have {(a,w')} {(a, v), (a, v')}, but 
Op = Eval* ({(a, v')}, (a,v)) ^ P Eval*({(a, v), (a, v')} , (a,«)) = 1 P . 

Eval* is monotonic for atomic policies if we adopt the ordering _Lp < Op < lp. 
This means that omitting attributes can cause the evaluation of an atomic policy 
to change from lp to Op or _Lp, or from Op to _Lp. While this seems to be 
reasonable, when combined with operators such as Ap, omitting attributes can 
cause the evaluation of a policy to change from Op to lp. We established in 
our work on PTaCL that certain operators (some of which are not used in this 
paper) are monotonic, while others, such as ->p and Vp are not monotonic [5]. 

4.4 A System with a Four- Valued Decision Set 

PTaCL is a recent proposal [8] that seeks to provide a stronger theoretical foun- 
dation for target-based policy languages such as XACML. PTaCL policies have 
a similar structure to those in XACML, although the operators used are some- 
what different, in order to combat the problem of non-monotonicity that might 
arise in target evaluation. However, PTaCL runs into a different type of non- 
monotonicity problem because atomic policies are evaluated in the way described 
in the previous subsection. 

The choice in the previous subsection to evaluate an atomic policy (a, v) to 
lp if (a,v) and (a 7 v') with v ^ v' and v,v' G dom(a) could be regarded as 



being logically inconsistent in the sense that the request also contains a non- 
matching value. One could equally well argue, for example, that the request 
should evaluate to Op. 

In order to cope with such situations, we might, therefore, choose to work 
with the 4-valued logic Four = {lp, Op, _Lp, Tp}, using Tp to denote conflicting 
information (in contrast to _Lp which signifies lack of information). We introduce 
the ordering where d\ ^4 d 2 if, and only if, d\ = _L, d\ = d 2 or d 2 = Tp, 
and we define 



Eval 4 (<j, (a,v)) = < 



Tp if q 9 (a, v), (a, v') such that v, v' G dom(a) and v' ^ v, 

lp if q 9 (a, v) and q (a, v') such that v' ^ v, 

Op if q $ (a, v) and q 9 (a, v') such that v 1 ^ v, 

_Lp otherwise. 



The definition of the policy operators Vp and Ap can be extended to unary 
operators on Four, where 

, (lp ifd = T P , , J Op ifd = T P , 

Vpd = < A P d = < 

I d otherwise; I d otherwise. 

Then the policy Vp(a,u) allows a request q whenever q contains a matching 
attribute, while the policy Ap(a,i>) denies a request q whenever q contains a 
non-matching attribute value. Although the notion of conflicting policy decision 
has already been studied [5], to the best of our knowledge, this is the first time 
this notion of conflict has been used to evaluate targets. Intuitively, a conflict 
indicates that the request provides too much information for this particular 
policy. 

Proposition 16 For all requests q and q' such that q q' and for all atomic 
policies (a, v), 

EvaU(<7, (a, v)) ^4 EvaU(<7', (a, v)). 

A possible way to extend the operators defined in Table [TJ is to consider the 
value Tp as absorbing: for any operator © : Three fe — > Three, we define the 
operator © : Four fe — > Four as follows: 



®(di,...,d k ) = 



Tp if there exists rfj = Tp, for 1 ^ i ^ k, 

®(di, . . . , dk) otherwise. 



Clearly, given an operator © defined over Three, if © is monotonic according to 
^3, then © is also monotonic with respect to ^4. It follows that we can still 
safely use the operators generated by the operators -ip, Ap, Vp and XXp, and 
we can deduce that any realizable policy is also monotonic. However, we lose 
the result of monotonic completeness, and we can no longer ensure that any 
monotonic operator can be generated from this set of operators. Obtaining such 
a result requires a deeper study of four-valued logic, and we leave it for future 
work. 



5 Concluding Remarks 

We have presented a generic framework for access control systems, within which 
a large variety of access control problems can be formalized, and which allows 
us to reason about the global properties of such systems. In particular, we have 
expressed the notions of monotonicity and completeness, and illustrated them 
using a particular instantiation of atomic policies that gives rise to a family of 
attribute-based access control models. 

A major strength of our approach is that we do not provide "yet another 
access control language" . The framework is not intended to provide an off-the- 
shelf policy language or PDP (unlike XACML, for example), nor is it intended 
to be an access control model (in the style of RBAC96). Rather, we try to model 
all aspects of an access control system at an abstract level and to provide a 
framework that can be instantiated in many different ways, depending on the 
choices made for request attributes, atomic policies, policy decisions and policy 
evaluation functions. In doing so we are able to identify (i) how and why an access 
control system may fail to be sufficiently expressive, and (ii) how and why having 
an expressive access control system may lead to vulnerabilities. In the context 
of the framework, we are able to define what we mean by monotonic policies, 
which provide strong guarantees about policy evaluation when the requests may 
be missing information or contain erroneous information. We are also able to 
define what we mean by a complete system, which provides guarantees about 
the expressivity of the system. 

Nevertheless our framework can be instantiated in ways that give rise to 
useful access control systems, and we have illustrated it with a monotonic and 
monotonically-complete attribute-based system, and with a complete attribute- 
based system. Moreover, the study of monotonicity and completeness in these 
concrete systems provides a better understanding of the issues that need to 
be considered when using those systems to specify authorization policies. In 
summary, the main technical contribution of this work is to provide a framework 
within which we can reason about important access control system properties 
such as expressivity and policy monotonicity. From a practical perspective, this 
work provides the developers of access control systems with a structured way 
of thinking about the design of such systems and to make them aware of the 
competing and conflicting considerations they need to consider. 

There are many opportunities for future work, some of which we have dis- 
cussed in previous sections. We believe that many other global properties of ac- 
cess control systems can be expressed within our framework and that tools from 
formal methods can be used to reason about the properties. For instance, in Sec- 
tion 13.31 we have outlined how the well-known safety problem in access control 
systems could be expressed within our framework. A very interesting question 
would be to identify the constraints on the components of our model for which 
problem becomes decidable. We also briefly sketch how we could perform static 
policy analysis, enabling us to check, for example, that a policy never returns _Lp 
for well-formed requests. Again, this is a question of considerable interest in the 
community |5I11] and one that we believe could be addressed within our frame- 



work. Our intuition suggests that this framework could also provide a basis for 
reasoning about privacy. It may be, for example, that a privacy-conscious user 
may wish or demand to withhold some attributes from an access control system. 
We conjecture that a property related to monotonicity will enable us to build 
useful access control systems that enable a user to disclose as little information 
as is required in order to gain access. Finally, in addition to instantiating this 
framework with other access control models, such as the different varieties of 
RBAC or XACML, we would like to study the composition of access control 
systems, and under what circumstances composition preserves properties such 
as monotonicity and completeness. 
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A Proofs 

Proposition [Til Let q.q' G Q such that q =q 1 q' . Then for all atomic policies 
(a, v), 

Eval(q, {a, v)) = Eval(q', (a, v)). 

Proof. We can write q and q' as gdcf U <z U ndcf and gdef U <?u n( j e f, respectively, 
where q un def is not necessarily equal to <Zu n dcf but ^ or au ( a > v ) e <Zundcf and all 
(a' , v') G <Zundef we have v — v' — o. Then, since Eval({(a, o)} , (a, v)) — _Lp for 
all a and all v, we have 

Eval(g, (a, v)) = Eval(g dcf , (a, v)) = Eval(g', (a, v)). 

Proposition [T2l Let Dec = {lp, Op, ^p}, and define x ^p y if and only if x = y 
or x = _Lp. Then for all requests q and q' such that q q' and for all atomic 
policies (a, v), 

Eval(g, (a,v)) ^ P Eval(q', (a, v)). 

Proof. We reason by case over the value of Eval(</, (a, v)). 

— If Eval(g, (a, v)) = _Lp, the proposition clearly holds by definition of ^p. 

— If Eval(g, (a,v)) = lp, then by definition of Eval, we know that (a,v) G q, 
which implies by definition of that (a, v) G q' , and thus we can conclude 
that Eval(<7', (a,v)) = lp. 

— If Eval((7, (a,v)) = Op, then by definition of Eval, there exists v' G dom(cv) 
such that (a, v') G q and v' ^ v. By definition of ^g, it follows that (a, v') G 
q' , and since a request can only contain one value per attribute, we can 
conclude that Eval(g', (a,v)) — Op. 

Proposition [TBI For all requests q and q' such that q ^g q' and for all atomic 
policies (a, v), 

Eval(g, (a,v)) < P Eval(g', (a, v)). 

Proof. We reason by case over Eval(q, (a, v)). 

— If Eval(g, (a,v)) = _Lp, then we can trivially conclude. 

— If Eval(g, (a, v)) — lp, then by definition of Eval, we know that (a, v) G 
q, which implies by definition of ^g that (a, v) G q'. It follows that 
Eval(q', (a,vj) is equal either to lp or to Tp, and thus we can conclude. 



— If Eval(q, (a,v)) = Op, then by definition of Eval, there exists v' G dom(a) 
such that (a, v') G q and v' ^ v. By definition of ^g, it follows that (a, v') G 
q', and therefore either Eval(g', (a, v)) — Op or Eval(<?', (a, v)) = Tp, allowing 
us to conclude. 

— If Eval(q, ((*,«)) = T, then by definition of Eval, (a,v) G q and there exists 
v' G dom(a) such that (a, u') G q and v' ^ u. By definition of ^g, we have 
(a, v) G g' and (a, v') G q', and thus we can conclude that Eval(q', (a,v)) — 
T. 

B Examples 

We illustrate the framework with two well-known examples from the literature: 
an information- flow model [1] and a role-based access control (RBAC) model [TO] . 
The examples are intended to illustrate the versatility of the framework. We 
assume the reader is familiar with the models concerned. 

Information Flow. Consider an information flow policy [1 which states that 
a user request to read a file is authorized provided the security level associated 
with the user is at least as high as that associated with the file. 

A user requests read access to a file then an authorization query could be 
presented to the PDP as a 4-tuple (u,f,b, read), where b is a flag that is set 
(by the context handler) if and only if X(u) A(/). We write <2if for this set of 
queries. We also define DeciF = {lp,0p,_Lp}. 

We define the set of atomic policies A\f = {allRead, isGtrThan}, such that 
allRead allows all read requests and isGtrThan permits any request in which 
the security level of the subject is greater than that of the subject. The valuation 
for these policies is defined as: 



Note that X(u) ^ A(/) does not imply X(u) < X(f), since the set of security 
levels may be a partial (not a total) order. Hence, it is not appropriate for 
Eval(q, isGtrThan) to return Op in the case that q is not of the form (u, f, a, 1). 

We introduce the set of operators Ops !F = {A, ?, ~}, whose definitions can be 
found in Table [1] These operators allow us to define two different policies to ad- 
dress the information flow problem: pi = (allowReadAisGtrThan), which (infor- 
mally) says "if it is a read request and the security level of the user is greater than 
that of the file, then allow; otherwise deny" ; p2 — allRead?(^ isGtrThan), which 
returns the evaluation of ~ isGtrThan if it is a read request and ~ isGtrThan 




Table 2. Evaluation of information flow requests 





allRead 


isGtrThan 


Pi 


~ isGtrThan 


V2 


(«,/, read, 1) 


lp 


lp 


lp 


lp 


lp 


(it,/, read,0) 


lp 


-Lp 


-L P 


Op 


Op 


(u,/, write, 1) 


-Lp 


lp 


-L P 


lp 


-Lp 



returns Op whenever isGtrThan does not return lp. We present in Table [2] some 
examples of evaluation of these policies. 

Note that the difference between p\ and p2 is that p2 denies explicitly a 
request for read request for which the level of the user is not greater than that 
of the object, while p\ does not return a conclusive decision for such a request. 

Using the previous definitions, we can define the system for information poli- 
cies as: 

SlF = (Qif, {allRead, isGtrThan} , {1 P , P , _L P } , {A, ?, , Eval| F ) 

Clearly, the policies p\ and pi defined above are some of the policies realizable by 
S'if, but many other policies can be generated from this system, for instance the 
policy (~ allRead), that allows all read accesses and denies all other accesses. 

This information-flow system can be extended to also write accesses by intro- 
ducing two atomic policies allWrite and isLessThan, which allow write access 
and accesses where the level of the user is less than the one of the resource, 
respectively. Note that since A(u) ^ A(/) does not imply X(u) < A(/), we would 
have to extend the request structure to also include a boolean attribute indicat- 
ing if X(u) ^ A(/). Due to space limitations, we do not describe the valuations of 
these atomic policies here, but they are clearly analogous to those for allRead 
and isLessThan. Finally, the complete information flow policy can be defined 
as ((allRead ? (~ isGtrThan)) A (allWrite ? (~ isLessThan)). 



RBAC. The role-based access control (RBAC) model [TU] introduces the notion 
of roles, to which users and permissions are assigned. A request, modeled as a 
session-permission pair, is allowed if and only if the session - a subset of the 
roles assigned to the user associated with the session - contains at least one role 
that is assigned to the permission. 

In our framework, a request has the form ({ri, . . . , r^} ,prm), where s = 
{ri, . . . , ffc} is a session and prm is a permission. We write Qrbac for the set of 
such requests. We define DecRBAC = {lp,0p}. 

We define one atomic policy for each pair (r,prm) G PA, where PA is the 
permission-role assignment relation. The valuation function for an atomic policy 
is therefore quite straightforward: 



Eval RB Ac((-!>i, . . . , r k },prm), (r,prm')) 



Op if r $ s or prm ^ prm 1 , 
lp otherwise. 



Given a relation PA, the corresponding RBAC policy is simply the disjunction 
of all atomic policies. Hence, it is sufficient to limit the set of operators to 
DecRBAC = {V}. Note that it means it is also possible to generate a less permissive 
policy by excluding some atomic policies. The access control system for RBAC 
is given by: 

Srbac = (Qrbac, PA, {1 p , P } , {V} , Eva I rbac ) 



